r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r? @Amanieu

@Amanieu the tidy issue highlights an annoying and unforeseen side-effect of this change. The vec module is now part of the prelude. In effect this means that for example this code:

fn xx(i: vec::IntoIter<i32>) {
    let _ = i.as_slice();
}

fn main() {}

that currently doesn't compile on stable would now compile. Initially I thought this would cause name collisions if users define their own vec module but so far I wasn't able to produce those, it seems to always prefer the local module. But regardless, I think we don't want to allow access to a standard library namespace without going through std, alloc or core. AFAIK there is no way to pub use only the macro and not the module namespace without modifications. I have two ideas how to tackle this, maybe we can rename vec to vec_xx internally and have separate use expressions or we have to add another crate that we can #[macro_use] inject into the prelude that only contains the vec macro. Thoughts?

See also:

• 2024 edition prelude item docs are not inlined, and cause some duplication and confusion #136102

There's an issue for this change - #53977.

@Voultapher, avoiding the vec module re-export can be done like this:

#[macro_export]
macro_rules! myvec {
    () => {};
}

pub mod myvec {
    pub struct Vec;
}

pub mod prelude {
    // Bad: re-exports both macro and type namespace
    // pub use crate::myvec;
    
    mod vec_macro_only {
        #[allow(hidden_glob_reexports)]
        mod myvec {}
        pub use crate::*;
    }
    pub use self::vec_macro_only::myvec;
}

fn main() {
    prelude::myvec!();
    let _: prelude::myvec::Vec; // error
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e50828c593e04ba0e98f48c9d8696b4

I've applied the suggestion by @dtolnay local tests seem promising. @Kobzol could we please do a timer run to see if this PR impacts compile-times.

env and panic (and maybe something else now?) need to be treated in the same way as vec.

@Voultapher Based on the CI failure I think that a try build would fail now.

Ok, I'll try to get the CI passing first.

@petrochenkov I went through all macros and searched the docs and env and panic seem to be the only other ones affected.

@Amanieu this program previously worked:

use std::*;

fn main() {
    panic!("panic works")
}

and now runs into:

error[E0659]: `panic` is ambiguous
   --> src/main.rs:4:5
    |
4   |     panic!("panic works")
    |     ^^^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `panic` could refer to the macro imported here
   --> src/main.rs:1:5
    |
1   | use std::*;
    |     ^^^^^^
    = help: consider adding an explicit import of `panic` to disambiguate
    = help: or use `crate::panic` to refer to this macro unambiguously
note: `panic` could also refer to the macro defined here
   --> rust/library/std/src/prelude/mod.rs:157:13
    |
157 |     pub use super::v1::*;
    |             ^^^^^^^^^

I don't see how we can resolve that without changing language import rules and or special casing the prelude import.

@petrochenkov Do you have any ideas about that?

Could you add a test making sure that the modules vec, env and panic are not in prelude?

@petrochenkov Do you have any ideas about that?

The ambiguity wouldn't happen if it was the same panic in std root and in the stdlib prelude.
However, std and core have two different panic macros.

Previously #[macro_use] extern crate std; would add the std's panic to macro_use prelude, and #[macro_use] extern crate core; would add the core's panic.
This PR always adds the core's panic.

#141934 has landed, unblocking.
@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

I'll try to get to it next week.

I've rebased the branch on master and fixed some outstanding issues. However there is still one issue remaining and that's related to the where-allowed test. Digging into it I found the following code works on nightly, but not with this version:

#![feature(custom_inner_attributes)]
#![rustfmt::skip]
use std::fmt::Debug;

fn in_parameters(_: impl Debug) { todo!() }

fn main() {}

error: cannot determine resolution for the macro `todo`
 --> src/main.rs:6:35
  |
6 | fn in_parameters(_: impl Debug) { todo!() }
  |                                   ^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

If #![rustfmt::skip] is uncommented both versions can compile it. Intuitively I fail to see how the additional #![rustfmt::skip] attributes should get the resolver stuck. I suspect it's some kind of compiler bug, maybe connected to the bug that makes some errors disappear in the where-allowed test. I'm looking into it, but don't feel particularly hopeful that I'll find the issue, given my lack of knowledge in the area.

EDIT: This is likely a red herring for another issue. Ignore it for now.

☔ The latest upstream changes (presumably #143057) made this pull request unmergeable. Please resolve the merge conflicts.

There was another issue with the alloctests, that I managed to resolve, the where-allowed and potentially unrelated custom_inner_attributes issue are still under investigation. To progress further, I've temporarily disabled the where-allowed test to see if there are other outstanding CI issue.

The job aarch64-gnu-llvm-19-2 failed! Check out the build log: (web) (plain enhanced) (plain)

##[endgroup]
[TIMING] core::build_steps::tool::ToolBuild { compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, tool: "linkchecker", path: "src/tools/linkchecker", mode: ToolBootstrap, source_type: InTree, extra_features: [], allow_features: "", cargo_args: [], artifact_kind: Binary } -- 0.157
[TIMING] core::build_steps::tool::Linkchecker { compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } -- 0.000
##[group]Testing stage0 Linkcheck (aarch64-unknown-linux-gnu)
std/prelude/v1/macro.panic.html:11: broken link - `std/prelude/std/fmt/index.html`
std/prelude/v1/macro.panic.html:16: broken link - `std/prelude/std/panic/fn.set_hook.html`
std/prelude/v1/macro.panic.html:20: broken link - `std/prelude/std/panic/fn.panic_any.html`
std/prelude/v1/macro.panic.html:42: broken link - `std/prelude/book/ch09-00-error-handling.html`
std/prelude/v1/macro.panic.html:43: broken link - `std/prelude/std/result/index.html`
std/prelude/v1/macro.panic.html:52: broken link - `std/prelude/std/panic/fn.panic_any.html`
core/prelude/v1/macro.env.html:7: broken link - `core/prelude/std/env/fn.var.html`
core/prelude/v1/macro.panic.html:11: broken link - `core/prelude/std/fmt/index.html`
core/prelude/v1/macro.panic.html:16: broken link - `core/prelude/std/panic/fn.set_hook.html`
core/prelude/v1/macro.panic.html:20: broken link - `core/prelude/std/panic/fn.panic_any.html`
core/prelude/v1/macro.panic.html:42: broken link - `core/prelude/book/ch09-00-error-handling.html`
core/prelude/v1/macro.panic.html:43: broken link - `core/prelude/std/result/index.html`
core/prelude/v1/macro.panic.html:52: broken link - `core/prelude/std/panic/fn.panic_any.html`
checked links in: 22.3s
number of HTML files scanned: 46442
number of HTML redirects found: 14496
number of links checked: 2557995
number of links ignored due to external: 95844
number of links ignored due to exceptions: 24
number of intra doc links ignored: 9
errors found: 13
found some broken links
NOTE: if you are adding or renaming a markdown file in a mdBook, don't forget to register the page in SUMMARY.md
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:35
  local time: Mon Jul  7 12:12:50 UTC 2025
  network time: Mon, 07 Jul 2025 12:12:50 GMT
##[error]Process completed with exit code 1.
Post job cleanup.